Kein Softwareentwickler ist vor Fehlern gefeit. Grössere Projekte investieren bis zu einem Drittel der Projektdauer in die Entdeckung von Fehlern (Testen) und ihre Verbesserung (Debugging). Man unterscheidet zwei Fehlerkategorien:
Syntaxfehler verstossen gegen die Formvorschriften einer Programmiersprache. Sie werden von der Entwicklungsumgebung zur Übersetzungszeit (engl. at compile time) oder seltener zur Laufzeit eines Programms (engl. at run time) entdeckt.
Logische Fehler verstossen gegen die Spezifikation der Anwendung. Sie werden in der Regel erst zur Laufzeit durch systematisches Testen entdeckt.
Während die Syntax ("Grammatik") die Form eine Programmiersprache vorschreibt, regelt die Semantik ihre Bedeutung. Die Semantik definiert, wie das Ergebnis einer Formel oder eines Algorithmus zustande kommt. Die Prüfung der Syntax übernimmt in der Regel der Compiler. Die Entdeckung von Semantikfehlern obliegt hingegen dem Entwickler. Er muss mit aufwendigen Tests prüfen, ob die Anwendung das tut, was die Spezifikation von ihr erwartet. Die folgenden umgangssprachlichen Beispiele veranschaulichen den Unterschied zwischen Syntax- und Semantikfehlern:
Die Aussage “Der Rhein fliesst träge” enthält weder syntaktische noch semantische Fehler.
“Der Rhein fliesst bunt” ist zwar syntaktisch in Ordnung, semantisch macht sie aber keinen Sinn.
“Der Rhein bunt fliesst” ist sowohl syntaktisch als auch semantisch falsch.
Entwicklungswerkzeuge erleichtern das Auffinden und Beheben von Fehlern. Ein Debugger (dt. “Entwanzer”) jener Teil der Entwicklungsumgebung, welcher die systematische Fehlersuche und -korrektur unterstützt. Mit dem Debugger kann die Entwicklerin zum Beispiel die Ausführung des Programms nach jeder Zeile anhalten und so Logikfehler (engl. bugs, “Wanzen”) besser identifizieren. Im Debugger kann die Entwicklerin insbesondere ...
einen beliebigen Programmausschnitt zeilenweise ausführen lassen (engl. stepwise debugging).
Haltepunkte definieren, an denen das Programm stoppt.
den Inhalt beliebiger Variablen inspizieren.
programmiersprachliche Überwachungsausdrücke definieren, die Programminhalte (allenfalls transformiert) anzeigen.
Der folgende Bildschirmauschnitt veranschaulicht die Funktionen b und d am Debugging der Ereignisprozedur KkBenutzerlösung_Click() (vgl. Hilfethema Gültigkeitsprüfung). Beim Lösen einer Mehrfachwahlaufgabe darf der Benutzer höchstens eine der vier Alternativen wählen. Die Ereignisprozedur für ein Kontrolkästchen der Spalte Lösung sei fehlerhaft, weil sie - wie auf dem Bildschirmausschnitt angezeigt - zwei Markierungen erlaubt. Richtig ist die Klickprozedur KkBenutzerlösung_Click() erst, wenn der Benutzer nach dem zweiten Markierungsversuch die Fehlermeldung "Markieren Sie nur e i n e Alternative" erhält.
Wir zeigen nun, wie der Debugger die Korrektur dieses logischen
Fehlers erleichtert. Der nächste Bildschirmausschnitt stammt aus MS Access und illustriert die folgenden Debuggingschritte:
Die Entwicklerin setzt einen Haltepunkt auf jenen Teil des Programms, in dem sie den Fehler vermutet. Access markiert Haltepunkte braun.
Die Entwicklerin führt den fehlerhaften Teil des Programms aus der Benutzersicht aus. In unserem Beispiel ist dies ein zweiter Markierungsversuch (obiger Bildschirmausschnitt).
Sobald das Programm den Haltepunkt betritt, wechselt MS Access von der Benutzersicht zum Debugger (untenstehender Bildschirmauschnitt).
Die Entwicklerin kann nun durch wiederholtes Drücken der Taste »F8 den Code Zeile für Zeile ausführen. Der Debugger markiert die jeweilige Zeile gelb.
Sobald die Entwicklerin mit dem Cursor auf einer Variable verweilt, erscheint deren Wert in einem hellgelben Kästchen.
Der Variablenwert [KkBenutzerlösung]
= -1 und die gelb markierte Codezeile legen die folgende Diagnose nahe:
Gemäss Spezifikation müsste das Programm die If-Anweisung betreten und mit MsgBox eine Fehlermeldung anzeigen. Dies geschieht nicht, weil die Bedingung [KkBenutzerlösung] = False nicht auf den Wert des markierten Kontrollkästchens zutrifft. Die Entwicklerin realisiert erst jetzt, dass die Variable [KkBenutzerlösung] nach einem Klick auf ein leeres Kontrollkästchens bereits den Zustand nach dem Klickereignis - also die Markierung bzw. den Wert True - anzeigt. Sie setzt deshalb die If-Bedingung auf [KkBenutzerlösung] = True und "entwanzt" so die Ereignisprozedur erfolgreich.
Oft kann die Entwicklerin
nicht alle möglichen Fehler vorausschauend
vermeiden. Die meisten Programmiersprachen bieten deshalb die Möglichkeit, Fehlerbehandlungscode
einzufügen, welcher die Auswirkungen zur Laufzeit auftretender Fehler (z.B. des
Öffnens einer nicht existierenden Datei) minimiert. Mehr Informationen zur Fehlerbehandlung von MS Access und Visual
Basic erfahren Sie unter 
Fehlerbehandlung.
Programmierfehler liegen nicht immer in der Verantwortung des Entwicklers. Oft sind auch Bugs des Enwicklungswerkzeugs der Grund schwer zu entdeckender Fehler. Erkundigen Sie sich auf der Website des Entwicklers! (für MS Access ist dies http://search.support.microsoft.com/kb/). Der Code zu TESTS kommentiert Tool Bugs mit dem Präfix '??.
